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EXECUTIVE  SUMMARY 


Current  FAA  regulations  allow  all  nonprecision  and  precision  Category  I  and 
Category  II  approach  and  landing  operations  to  include  a  transition  from 
instrument  flight  to  visual  flight,  followed  by  a  "fly  visual"  segment  to 
complete  the  landing.  As  a  means  for  increasing  airport  capacity,  numerous  "fly 
visual"  concepts  have  been  envisioned  -  simultaneous  charted  visual  approaches 
to  closely  spaced  parallel  runways,  simultaneous  instrument  approaches  to  closely 
spaced  runways,  simultaneous  visual  approaches  to  intersecting  runways,  and 
simultaneous  converging  instrument  approaches  to  intersecting  runways.  To  date, 
very  little  qualitative  and  quantitative  data  are  available  for  use  in  evaluating 
the  safety  of  these  concepts. 

The  Standards  Development  Branch  (AVN-540)  at  the  Mike  Monroney  Aeronautical 
Center,  Oklahoma  City,  requested  that  data  be  collected  to  be  used  to  formulate 
criteria  for  conducting  simultaneous  visual  operations  to  parallel  runways  having 
spacing  less  than  established  standards  and  to  converging  runways.  The  Dual 
Sensor  Receivor  and  Processor  (DUALSRAP)  Data  Collection  System  data  collection 
system  previously  used  to  collect  data  at  the  Chicago  O'Hare  International 
Airport  (ORD)  was  modified  to  collect  the  necessary  data.  The  system  used 
position  reports  generated  by  the  Airport  Surveillance  Radar  (ASR)-7  along  with 
its  associated  secondary  radar,  the  Air  Traffic  Control  Beacon  Interrogator 
(ATCBI)-4.  Data  was  collected  on  arriving  targets-of-opportunity  aircraft  to  San 
Francisco  International  Airport  (SFO) .  These  arriving  aircraft  had  to  be 
equipped  with  Mode  C/S  transponders  while  conducting  the  Quiet  Bridge  and  Tipp 
Toe  visual  approaches  to  runways  28R  and  28L,  respectively.  The  data  collection 
began  November  1989  and  continued  until  March  1990  when  the  required  number  of 
approximately  3000  tracks  had  been  recorded.  Voice  recordings  of  all 
communications  between  observed  aircraft  and  air  traffic  control  were  also 
obtained,  along  with  accurate  and  timely  weather  data. 

Data  processing  and  reduction  was  done  at  the  FAA  Technical  Center,  resulting  in 
smooth  track  files  and  various  plots  of  the  data.  The  reduced  track  data  files 
and  their  plots  were  sent  to  AVN-540.  A  Master  data  base  was  constructed  and 
provided  all  pertinent  data  and  certain  aspects  important  to  analysis.  Limited 
data  analysis  was  performed  at  the  FAA  Technical  Center  in  order  to  determine  the 
overall  accuracy  of  the  collected  data.  AVN-540  will  conduct  the  final  analysis 
of  the  reduced  data  and  report  on  their  findings  and  recommendations. 
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1 .  INTRODUCTION . 


The  Visuals  Approach  Final  Report  describes  the  data  collection  and  reduction 
methodology  that  was  employed  to  provide  the  Standards  Development  Branch,  AVN- 
540,  with  the  data  they  requested.  These  data  were  part  of  an  operational  test 
and  evaluation  of  the  visual  segment  of  approaches  to  runways  28L  and  28R  at  the 
San  Francisco  International  Airport  (SFO) .  The  final  report  is  intended  to 
accomplish  the  following: 

a.  Describe  the  data  collection  and  data  reduction  hardware  and  software. 

b.  Specify  the  data  collection  and  data  reduction  procedures. 

c.  Describe  the  deliverables  for  which  the  Engineering,  Research,  and 

Development  Service,  Air  Traffic  Control  (ATC)  Technology  Branch,  ACD-340  was 
responsible . 

d.  Discuss  general  conclusions  derived  from  preliminary  ACD-340  data 

analysis . 

e.  Provide  the  milestone  project  schedule. 

1.1  OBJECTIVES. 

The  objective  of  this  effort  was  to  provide  an  accurate  data  base  of  the 
navigational  accuracy  of  aircraft  flying  the  visual  approaches  to  the  closely 
spaced  parallel  runways  at  SFO  under  different  environmental  conditions.  It 

sought  to  describe  the  current  use  and  practices  during  day  in,  day  out 

operations.  This  data  base  will  be  used  by  AVN-540  to  determine  operating 
miniraums,  operational  criteria,  and  operational  procedures  associated  with 
certain  "fly  visual"  approach  and  landing  operations. 

1.2  BACKGROUND. 

Airport  capacity  remains  a  critical  issue  for  the  Federal  Aviation  Administration 
(FAA) .  The  ability  of  a  highly  active  airport  to  operate  at  its  optimal  capacity 
is  crucial  to  daily  operations.  One  method  to  maintain  airport  capacity  is  to 
permit  standard  Instrument  Flight  Rules  (IFR)  separation.  Operations  based  on 
IFR  separation,  however,  have  not  accommodated  the  capacity  requirements  at 
specific  airports.  The  increases  in  traffic,  plus  the  limited  number  of  runways 
where  standard  IFR  separation  can  be  applied,  have  led  to  the  increased  use  of 
the  fly  visual  concept  in  operations.  The  fly  visual  concept  provides  standard 
IFR  separation  until  the  aircraft  arrive  at  a  point  where  visual  separation  must 
be  established  by  either  the  pilots  or  the  controller.  In  simultaneous  fly 
visual  operations,  this  usually  occurs  just  prior  to  arriving  at  the  point  where 
the  two  flightpaths  converge  to  the  required  minimum  IFR  lateral  separation 
distance.  Flight  standards  are  needed  to  establish  criteria  and  operational 
requirements  necessary  to  safely  conduct  simultaneous  fly  visual  operations  for 
simultaneous  visual  approaches  to  closely  spaced  parallel  runways  which  have  a 
fly  visual  segment  (based  on  visual  separation) ,  as  well  as  to  converging 
runways . 
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2.  RELATED  PROJECTS  AND  DOCUMENTATION. 


A  recent  work  effort  conducted  by  the  ATC  Technology  Branch,  ACD-340,  under  the 
Capacity  Studies  project,  F20-06A,  resulted  in  the  development  and  employment  of 
the  Dual  Sensor  Receiver  and  Processor  (DUALSRAP)  Data  Collection  System.  The 
DUALSRAP  system  collected  data  from  a  Sensor  Receiver  and  Processor  (SRAP)  which 
was  connected  to  the  source  of  radar  data.  The  source  consisted  of  an  Airport 
Surveillance  Radar  (ASR)-7  and  an  ATC  Beacon  Interrogator  (ATCBI)-4.  This  system 
was  used  to  characterize  the  Instrument  Landing  System  (ILS)  navigational 
performance  of  a  typical  mix  of  today's  aircraft,  and  to  determine  the  degree  of 
containment  within  several  hypothetical  Normal  Operating  Zones  (NOZ)  smaller  than 
presently  allowed.  The  system  was  set  up  at  Chicago  O'Hare  International  Airport 
from  January  1989  through  March  1989  to  collect  a  data  base  of  over  3000 
simultaneous  ILS  approaches.  The  DUALSRAP  Data  Collection  System  was  employed 
by  this  project  with  some  system  modifications.  System  modifications  included 
termination  of  data  collection  at  a  preset  time  and  modification  of  system 
defaults  for  SFO  data  collection.  Additional  software  was  used  to  facilitate 
automatic  start  up  of  data  collection  and  provide  for  remote  monitoring  and 
control  of  data  collection.  Additionally,  a  local  area  network  was  installed  to 
provide  the  ability  for  on-site  plotting  of  data  and  better  utilization  of  disk 
space  and  computers.  A  more  detailed  description  of  the  DUALSRAP  Data  Collection 
System  was  supplied  by  Thomas  and  Timoteo,  April  1990. 

3.  PROJECT  IMPLEMENTATION. 

The  primary  data  for  this  study  were  radar  tracks  of  aircraft  flying  visual 
approaches  to  the  closely  spaced  parallel  runways  28L  and  28R  at  SFO.  Airport 
diagrams  are  shown  in  figures  1,  2,  and  3.  In  order  to  extract  the  maximum 
information  from  this  data,  secondary  data  collected  included  the  precise  weather 
conditions  during  the  approach,  the  type  of  aircraft,  the  aircraft's  beacon  code 
and  identification,  and  the  approach  fix  for  each  aircraft.  Approximately  3000 
aircraft  tracks  were  collected  in  order  to  provide  AVN-540  with  a  large  enough 
data  base  for  analysis. 

The  project  phases  were  divided  into  data  collection,  data  extraction  and 
reduction  with  limited  analysis,  and  data  output  to  Flight  Standards.  In 
addition,  system  support  software  was  modified  as  needed  to  accomplish  the 
project  goals. 

4.  DATA  COLLECTION. 

4.1  DATA  COLLECTION  HARDWARE. 

4.1.1  Data  Collection  System  Hardware  Description.  The  data  collection  system 
was  installed  partly  at  the  Bay  Terminal  Radar  Approach  Control  (TRACON)  and 
partly  at  the  Bay  radar  site  (shown  in  figure  4) .  It  consisted  of  the  following 
hardware ; 

a.  SRAP  (radar  site) . 

b.  Interface  Card  Cage  containing:  (radar  site) 
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QUIET  BRIDGE  VISUAL  APPROACH  RUNWAY  28R 


when  visual  approaches  to  Runway  28R  ore  in  progress,  arriving  oircraft  may 
be  vectored  into  a  position  for  o  stroight-in  visual  opprooch  to  Runway  28R  via 


the  SFO  VOR  R-095 . 


SFO  VOR  and  OME  must  be  operating. 

Aircraft  should  remain  on  the  SFO  R-095  until  passing  the  San  Mateo  Bridge. 
NOTE:  Closely  spaced  parallel  visual  approoches  may  be  in  progress  to  Runway 
281  utilizing  l-SFO.  In  the  event  of  o  go-oround  on  Runway  28R,  turn 
right  heading  310®,  climb  ond  maintain  3000,  or  as  directed  by  Air 
Traffic  Control. 
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PICTURE  2.  SFO  CHARTED  VISUAL  28R  APPROACH  PLATE 
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TIPP  TOE  VISUAL  APPROACH  RUNWAY  28L 

when  visual  approaches  to  Runway  28L  ore  in  progress,  arriving  aircrah  moy 
be  cleared  for  a  visual  approach  vio  the  OAK  VOR  R-151  ond  l-SFO  localizer. 
The  OAK  VOR  and  OME  and  l-SFO  must  be  operating. 

Aircraft  should  cross  the  OAK  R-151/16  DME  (Menlo  Int)  at  or  above  4000  and 
the  San  Moteo  Bridge  at  or  above  1900. 

NOTE:  Closely  spaced  parallel  visuol  approaches  may  be  in  progress  to  Runwoy 
28R  utilizing  the  SFO  R-095  In  the  event  of  a  go-around  on  Runway  28L, 
turn  left  heading  265°,  dimb  and  mointain  3000,  or  os  directed  by  Air 
Traffic  Control. 
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FIGURE  3.  SFO  CHARTED  VISUAL  28L  APPROACH  PLATE 
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PRIMARY  RADAR 


BEACON  RADAR 


DUALSRAP  DATA  COLLECTION  SYSTEM 
(as  used  at  San  Francisco) 


FIGURE  4,  DUALSRAP  DATA  COLLECTION  SYSTEM 
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1.  Two  SRAP  to  Personal  Computer  (PC)  interface  cards. 

2.  Sensor  Interface  to  PC  interface  card. 

3.  Digital  Altimeter  Setting  Indicator  (DASI)  interface  card. 

c.  Interfacility  Data  System  Microprocessor  (IDSM)  Interface  Unit  and  cables 
(TRACON) . 

d.  WWVB  Time  Code  Receiver  and  Antenna  (radar  site) . 

e.  IBM  PC  XT  Computer  System  with  Expansion  Chassis  (radar  site). 

f.  Zenith  Z-248  Computer  System  (radar  site). 

g.  IQ-Plus  XT  Compatible  Computer  (TRACON). 

h.  Two  Mountain  Filesafe  Series  7300  150  MB  Tape  Backups  (radar  site). 

i.  VLR-466  Voice  Logging  Recorder  (TRACON). 

j .  American  Power  Conversion  1200VX  Uninterruptible  Power  Supply  (radar 
site) . 

4 ■ 1 . 1 ■ 1  SRAP .  The  project  SRAP  accepted  analog  signals  from  the  ASR-7  and 
ATCBI-4  and  converted  the  data  into  digital  target  reports  used  by  the  ARTS  IIIA 
processor.  The  SRAP  consisted  of  a  Radar  Data  Acquisition  Subsystem  (RDAS)  and 
a  Beacon  Data  Acquisition  Subsystem  (BDAS).  The  RDAS  provided  detection  of  range 
and  azimuth  of  aircraft  targets  and  weather.  The  BDAS  provided  for  the  detection 
and  reporting  of  the  range,  azimuth,  altitude,  and  identity  of  transponder 
equipped  aircraft.  The  BDAS  also  received  data  from  t!  RDAS  in  order  to  perform 
radar/beacon  target  correlation.  Data  were  output  i  n  the  SRAP  via  the 
Peripheral  Interface  Module  (PIM)  in  the  form  of  eiir.  a  one,  two,  or  three 
32 -bit  word  message.  SRAP  output  consisted  of  the  following  message  types: 


Description 


1  Radar  only  reports  (2  words) 

Used  ASR  radar  video 


2  Beacon  only/radar  reinforced  beacon  reports  (3  words) 

Used  ATCBI  or  ATCBI/ASR  radar  videos 

3  Alarms  (1  word) 

Reported  SRAP  processing  errors 

4  Sector  mark  (1  word) 

Message  output  every  11.25°  of  radar  scan 


4. 1.1. 2  SRAP/XT  Interface.  FAA  Technical  Center  personnel  designed  and 
fabricated  a  SRAP  Interface  and  Control  card  set  that  served  as  an  interface 
between  a  PC  and  the  SRAP.  SRAP  data  were  obtained  from  the  PIM  using  two 
50-conductor  flat  cables.  The  interface  card  converted  32-bit  SRAP  message  words 
into  the  IBM  PC  8 -bit  word  format.  The  card  read  each  complete  SRAP  message  as 
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quickly  as  the  SRAP  could  send  it  (one,  two,  three  words).  Each  message  was 
broken  down  in  two,  four,  six,  or  twelve  8-bit  bytes.  An  interrupt  was  then  sent 
by  the  card  to  notify  the  PC  of  data  ready  to  send.  The  interface  card  supported 
the  four  previously  defined  SRAP  message  types.  The  interface  permitted 
simultaneous  collection  of  data  from  two  separate  RDAS/BDAS  subsystems  (SRAPO  and 
SRAPl) .  These  subsystems  can  be  connected  to  the  same  or  different  radar 
sources.  It  provided  the  following  preprocessing  functions  for  each  channel: 

a.  Automatic  synchronization  with  the  SRAP  data  by  sector  marks. 

b.  Identification  of  each  SRAP  data  report  type. 

c.  Filtering  by  sector  for  report  types  1  and  2  above. 

d.  Input,  reformatting,  and  storage  of  a  complete  SRAP  report. 

e.  Hardware  interrupt  to  XT  to  request  report  transfer. 

f.  Transmission  of  report  to  XT  via  input/output  (I/O)  channel  on  a  byte 
basis . 

The  interface  incorporated  azimuth  filtering  of  the  radar  and  beacon  only/radar 
reinforced  messages  based  on  sector  mark.  Board-mounted  DIP  switches  were  used 
to  select  both  a  start  and  stop  sector.  These  switches  were  set  prior  to  each 
test  to  restrict  collected  sectors  to  those  actually  used  by  the  aircraft  during 
approach  and  landing.  In  this  way  the  amount  of  unwanted  data  were  minimized, 
thereby  reducing  the  XT  workload  and  the  amount  of  collected  data.  The  sector 
switches  could  be  changed  during  a  test  without  stopping  collection.  In  this  way 
changing  approach  configurations  were  accommodated  while  minimizing  the  amount 
of  missed  data. 

4.1. 1.3  DASI/XT  Interface.  DASI  data  were  collected  by  the  DASI  interface  card. 
The  IBM  PC  polled  the  DASI  interface  card  every  4.7  seconds  to  see  if  data  were 
present . 

4. 1.1. 4  IDSM  Interface.  SFO  Interfacility  data  were  collected  via  the  Landrum 
and  Brown  Automated  Radar  Terminal  System  (ARTS)  Identification  Data  Acquisition 
System  (ID-DAS) .  The  ID-DAS  interface  consisted  of  a  Persyst  multiport  serial 
coprocessor  board,  a  distributed  communications  processor  capable  of  running 
independently  of  the  Host  PC,  and  the  ID-DAS  Fortran  software. 

4. 1.1. 5  Computer  Equipment.  The  computers  used  for  data  collection  were 
standard  IBM  XT  or  AT  Compatible  systems  with  a  number  of  add-on  cards.  The  IBM 
XT  and  the  Zenith  Z-248  were  located  at  the  radar  site.  The  IQ-PLUS  was  located 
at  the  TRACON.  A  dedicated  phone  line  at  each  site  was  required  for  remote 
monitoring  and  control  of  data  collection. 

The  IBM  XT  ran  the  DUALSRAP  program  that  collected,  time-tagged,  and  stored  SRAP 
and  DASI  data.  Add-on  cards  included  a  80286/80287  Turbo  card  with  onboard 
memory  cache  for  added  processing  power,  a  2  MB  expanded  memory  board,  a  LAN 
card,  and  a  2400  baud  modem. 
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The  Zenith  Z-248  AT  compatible  functioned  as  a  network  server  for  the  XT.  The 
Zenith  had  a  600  megabyte  drive  that  SRAP  and  DASI  data  were  saved  to  after  the 
day's  data  collection  finished.  The  Zenith  also  included  software  to  allow 
on-site  plotting  of  collected  data  while  the  XT  continued  to  collect  data.  Add¬ 
on  cards  included  2.5  MB  of  extended  memory,  a  2400  baud  modem,  and  a  LAN  card. 

The  IQ-PLUS  XT  Compatible  was  set  up  to  collect  interfacility  data.  Add-on  cards 
were  the  IDSM  interface  and  a  2400  baud  modem. 

A  personal  computer  located  at  the  FAA  Technical  Center  was  used  to  collect  the 
weather  data  for  SFO. 

4.1.2  Data  Collection  Interfaces.  Two  types  of  data  were  collected.  Aircraft 
track  data  was  collected  via  the  DUALSRAP  system.  Weather  and  pilot/  controller 
communications  were  collected  by  separate  systems.  More  detailed  descriptions 
of  the  individual  data  files  are  contained  in  appendix  A. 

4 ■ 1 . 2 . 1  DUALSRAP  Hardware  Interface .  The  DUALSRAP  data  collection  system,  shown 
in  figure  4  and  described  in  section  4.1.2,  interfaced  with  the  following 
hardware ; 

a.  ASR-7  and  ATCBI-4  search  and  beacon  radar,  via  a  SRAP. 

b.  Interfacility  Data  System  Microprocessor  (IDSM). 

c.  Digital  Altimeter  System  Indicator  (DASI). 

d.  WWVB  Reference  Time. 

Aircraft  position  was  determined  from  target  replies  provided  by  the  Bay  TRACON 
ASR-7  and  ATCBI-4.  Radar  videos  and  triggers  were  received  by  a  project-supplied 
SRAP  from  a  feed  on  the  TRACON  radar  distribution  amplifiers;  the  project  used 
the  same  raw  radar  data  used  by  the  operational  system.  The  SRAP  converted  the 
radar  analog  data  into  digital  processed  information  for  the  Automated  Radar 
Terminal  System  (ARTS)  IIIA  processor.  To  minimize  impact  to  the  San  Francisco 
ARTS,  the  project  obtained  a  surplus  SRAP  from  the  FAA  Depot  in  Oklahoma  City  for 
standalone  use.  This  SRAP's  analog  front  end  and  digital  parameter  settings  were 
brought  up  to  certification  standards  by  SFO  Airways  Facilities  personnel. 

The  SFO  interfacility  data  was  collected  from  the  IDSM.  The  IDSM  provided 
information  on  flights  in  the  National  Airspace  System  (NAS).  This  information 
consisted  of  each  flight's  beacon  code,  aircraft  ID,  aircraft  type,  approach  fix, 
and  altitude  at  the  fix.  The  information  was  transmitted  between  the  Bay  TRACON 
and  the  en  route  centers.  For  this  data  collection,  only  SFO  arrival  information 
was  extracted  and  stored  to  disk,  departures  and  over  flight  data  were  ignored. 

DASI  data  was  collected  at  SFO.  The  DASI  provided  local  digitized  barometric 
pressure  and  was  received  at  the  radar  site  from  the  IRACON  via  a  Radar  Microwave 
Link  (RML)-6. 

The  National  Bureau  of  Standards  (NBS)  WWVB  broadcast  station  located  in  Fort 
Collins,  Colorado,  was  used  as  the  data  collection's  reference  time  source.  WWVB 
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time  was  received  and  processed  by  a  commercially  available  unit  with  an  accurate 
internal  clock.  This  provided  a  stable  reference  at  the  site  when  radio 
reception  was  poor.  This  time  was  used  at  the  start  of  each  data  collection 
session  to  synchronize  the  PC  internal  real-time  clock  (Disk  Operating  System 
(DOS)  time).  The  DOS  time  was  then  used  to  time-stamp  each  of  the  SRAP  Sector 
reports  recorded  to  disk. 

4. 1.2. 2  Additional  Interfaces.  Data  obtained  from  these  sources  were  not  used 
by  DUALSRAP  during  the  data  collection  process.  These  data  were  used  in  the  data 
extraction  and  reduction  processes . 

The  SFO  National  Weather  Service  (NWS)  meteorological  reports  were  collected  once 
a  day  via  modem  from  the  Kavouras ,  Inc.  Meteorological  Data  Base  computer  located 
at  the  Minneapolis  International  Airport  (shown  in  figure  5).  Surface 
Observation  Reports  (SA)  were  normally  available  on  an  hourly  basis,  with  Special 
Reports  (SP)  given  more  frequently  when  warranted  by  rapidly  changing  weather 
conditions.  A  full  report  consisted  of  cloud  heights  and  coverage,  visibility, 
weather,  temperature,  dewpoint,  wind  direction  and  speed,  altimeter,  and  remarks . 
Remarks  were  conditions  considered  significant  to  aviation  such  as  runway 
visibility,  cloud  types,  icing  conditions,  etc. 

Voice  recordings  of  pilot/controller  communications  for  approach  control,  all 
local  control,  and  the  Air  Traffic  Information  Service  (ATIS)  channel  were  made 
on  a  4-channel  audio  recorder  interfaced  with  the  Granger  Link  Microwave  system. 
An  accurate  date  and  time-of-day  stamp  was  integrated  with  each  recorded  channel. 
This  allowed  searches  for  specific  portions  of  the  recordings  on  a  time  basis. 

4.2  DATA  COLLECTION  SYSTEM  SOFTWARE. 

4.2.1  SRAP  Data  Collection  Software.  An  ACD-340  written  8088  assembly  language 
program,  collected,  time-stamped,  and  stored  SRAP  and  DASI  data  to  disk. 
Assembly  language  was  used  for  maximum  speed  and  hardware  control.  The  program 
consisted  of  foreground  and  background  processes.  Since  DASI  data  collection  had 
a  relatively  low  data  rate,  the  background  process  polled  the  DASI  to  PC 
interface  card  every  4  secoVids.  SRAP  data  collection  had  a  much  higher  data  rate 
and  was  handled  by  the  foreground  routine  using  hardware  interrupts.  Collected 
SRAP  and  DASI  data  were  saved  into  buffers;  after  these  buffers  filled  up,  the 
data  were  written  to  disk. 

The  DUALSRAP  system  software  was  modified  to  allow  greater  flexibility  for  remote 
operation.  The  options  that  defined  the  system  configuration  for  a  given  session 
included: 

a.  Synchronization  of  DOS  time  with  WWVB  time  at  start  of  data  collection 
(synchronized  for  SFO). 

b.  Range  filtering  (4,  8,  16,  32,  or  64  miles)  of  collected  targets  with 
respect  to  radar  collection  (16  miles  for  SFO). 

c.  Collection  of  DASI  sensor  data  (collected  for  SFO). 
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WEATHER  DATA  COLLECTION  SYSTEM 
(as  used  at  FAA  Technical  Center) 


FIGURE  5.  WEATHER  DATA  COLLECTION  SYSTEM 
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d.  SRAP(s)  to  be  used  (SRAP  0  for  SFO) . 

e.  Collection  of  radar-only  messages  for  each  SRAP,  however,  these  messages 
had  limited  use  and  require  considerable  storage  space  and,  therefore,  were  not 
collected  for  SFO. 

f.  Termination  of  data  collection  at  a  preset  time  each  day  (2200  hours  for 
SFO)  . 

g.  Specification  of  Start  and  Stop  Sector  Marks  using  board-mounted 
switches . 

4.2.2  Interfacility  Data  Collection  Software.  An  executable  Fortran  program 
collected  and  stored  interfacility  data.  The  program's  configuration  had  to  be 
set  up  each  time  data  collection  was  started.  The  ID-DAS  provided  the  ability 
to  execute  the  collection  software  via  a  batch  command.  The  batch  command 
specified  a  redirected  input  file  with  the  necessary  responses  needed  to 
initialize  and  configure  the  software.  These  options  were  set  as: 

a.  Processing  mode  -  Arrivals  only  for  SFO  (Options  were  all  Operations, 
Arrivals,  Departures,  Not  Overflights). 

b.  Included  all  aircraft  ID's  for  SFO. 

c.  All  ARTS  Interfacility  messages,  pertinent  to  ID-DAS,  were  copied  to  a 
buffer  file. 

d.  Start  and  Stop  times  were  specified  for  SFO  (data  collection  began 
immediately  upon  program  execution  and  stopped  at  2200  hours). 

e.  Default  output  filename  set  for  SFO  (Imddhhmm. AOL  -  m  -  month,  dd  -  day, 
hh  -  hour,  and  mm  -  minute). 

4.2.3  Weather  Data  Collection  Software.  PC  Weather  was  a  telecommunications 
program  which  accessed  the  Kavouras  Inc.  Meteorological  data  base.  The  software 
was  set  up  to  call  up  and  log  onto  the  Kavouras  data  base,  request  the  30 
previous  SA  Reports,  save  the  reports  to  disk,  and  log  off  the  system.  Since  PC 
Weather  was  intended  primarily  to  be  used  as  an  interactive  program,  it  was 
necessary  to  use  Extended  Batch  Language  (EBL)  to  execute  the  program  unattended. 
EBL  was  used  to  execute  the  following  actions  in  the  weather  data  collection 
program: 

a.  Dial  the  weather  data  base. 

b.  Enter  the  User  Name  and  Password  to  gain  access  to  the  system. 

c.  Send  the  command  "SA/SFO  RPTS-30,"  which  requested  the  last  30  SA  reports 
for  SFO. 

d.  Request  that  the  weather  data  be  saved  to  disk. 

e.  Log  off  the  data  base  and  then  exit  the  data  collection  program. 


12 


4.2.4  Data  Collection  Support  Software.  Various  off-the-shelf  software  packages 
were  used  to  support  the  SFO  data  collection  effort.  The  support  software  were 
supplied  by  Mountain  Computer,  Inc.,  Fox  Software,  Inc.,  Seaware  Corporation, 
Novell  Incorporated,  and  Dynamic  Microprocessor  Associates,  Inc. 

4. 2. 4.1  Autorun.  Autorun  is  a  program  supplied  with  the  Mountain  Filesafe  Tape 
Backup  software.  The  program  executed  appointments  based  on  the  DOS  time  and 
date  of  a  computer.  Autorun  was  used  to  start  the  SRAP  and  Interfacility  data 
collection  each  day. 

4. 2. 4. 2  Foxbase .  Foxbase  +2.10  is  a  data  base  management  program.  When  daily 
data  collection  was  started,  a  Foxbase  language  program  was  executed.  This 
program  created  DOS  batch  files  that  were  used  to  rename  data  collection  files, 
to  set  the  attributes  of  those  files,  and  to  delete  the  files  at  various  stages 
of  the  data  collection.  For  a  more  detailed  description  of  these  batch  files, 
refer  to  appendix  D  of  this  report. 

4 . 2 . 4 . 3  EBL.  Extended  Batch  Language  is  a  command  programming  language.  The 
"Keyboard  Stack"  feature  of  EBL  was  used  for  weather  data  collection  and  allowed 
for  answering  questions  within  programs  without  operator  intervention.  Data 
placed  in  the  "stack"  was  seen  by  the  weather  data  collection  program  during 
execution  as  operator  input. 

4. 2. 4. 4  Novell  NetWare.  NetWare  was  used  to  set  up  the  local  area  network  for 
the  IBM  XT  and  the  Zenith  Z-248  computers  at  SFO  with  the  Z-248  being  used  as  the 
network  server. 

4. 2. 4. 5  pcAnvwhere.  pcAnywhere  is  a  remote  access  software  package  that 
provided  for  remote  monitoring  and  operation  of  the  project  computers  via  modem 
from  the  FAA  Technical  Center. 

4,3  DATA  COLLECTION  PROCEDURES. 

After  the  data  collection  procedures  were  established,  it  was  not  necessary  to 
have  ACD-340  personnel  on-site.  Data  collection  was  monitored  and  operated  by 
ACD-340  personnel  at  the  FAA  Technical  Center. 

4.3.1  SRAP  Data  Collection  Procedures.  The  SRAP  and  DASI  data  collection 
process  consisted  of  various  programs  invoked  by  a  batch  file.  The  batch  file  was 
started  on  the  IBM  XT  each  day  at  0600  hours  (Pacific  time)  by  an  appointment 
scheduling  program.  Autorun.  The  batch  file  initiated  the  following  procedures: 

a.  Created  DOS  batch  files  that  were  later  executed  during  data  collection 
to  rename,  set  attributes  of,  and  delete  data  files. 

b.  Started  the  DUALSRAP  data  collection  program.  This  program  ran  from  the 
time  .'.t  was  started  until  2200  hours  (Pacific  time)  . 

c.  After  the  data  collection  program  terminated,  the  names  of  the  SRAP, 
DASI,  and  message  data  files  were  changed  to  reflect  the  month,  day,  and  hour  of 
that  day's  data  collection.  The  day’s  data  were  then  saved  to  the  network  drive. 
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d.  Primary  and  secondary  tape  backups  of  the  day's  data  files  were 
performed. 

e.  If  the  day's  data  were  successfully  copied  to  the  network  drive,  then  the 
day's  data  files  were  deleted  from  the  XT's  hard  drive. 

If  any  problems  occurred  during  data  collection  and  the  XT  had  to  be  rebooted, 
the  data  collection  batch  file  could  be  restarted  manually  by  on-site  personnel 
or  remotely  by  FAA  Technical  Center  personnel.  For  more  details  on  the  SRAP  data 
collection  procedures,  refer  to  appendix  D  of  this  report. 

4.3.2  Interfacility  Data  Collection  Procedures.  The  Landrum  and  Brown  ARTS 
ID-DAS  was  invoked  by  a  batch  file.  The  batch  file  was  started  on  the  IQ-PLUS  XT 
PC  compatible  each  day  at  0500  hours  (Pacific  time)  by  Autorun.  Interfacility 
data  collection  started  1  hour  before  SRAP  data  collection.  The  earlier  start 
time  accounted  for  the  up  to  1  hour  time  difference  between  the  receipt  of 
interfacility  data  for  an  aircraft  and  the  aircraft's  arrival  time  at  the 
airport.  The  batch  file  initiated  the  following  procedures: 

a.  Checked  for  the  existence  of  old  data  files  in  the  interfacility  data 
subdirectory  on  the  IQ- PLUS  hard  drive.  If  any  files  were  present,  they  were 
deleted. 

b.  Set  up  configuration  and  started  execution  of  the  interfacility  data 
collection  program.  This  program  ran  from  when  it  was  started  until  2200  hours 
(Pacific  time) . 

c.  Backed  up  the  day's  data  to  hard  disk  and  onto  floppy  disk. 

If  any  problems  occurred  during  data  collection  necessitating  a  reboot  of  the  IQ- 
PLUS,  interfacility  data  collection  may  be  restarted  manually  either  remotely  or 
by  on-site  personnel.  For  more  detail  on  interfacility  data  collection 
procedures,  refer  to  appendix  D. 

4.3.3  Weather  Data  Collection  Procedures.  The  weather  data  collection  process 
was  invoked  by  a  batch  file.  The  batch  file  was  started  on  an  IBM  compatible 
computer,  located  at  the  FAA  Technical  Center,  each  day  at  0100  hours  (Eastern 
time)  by  Autorun.  The  batch  file  initiated  the  following  procedures; 

a.  Checked  for  the  existence  of  old  data  files  in  the  weather  data 
subdirectory  on  the  computer's  hard  drive.  If  any  files  were  present,  they  were 
deleted. 

b.  Set  up  configuration  and  started  execution  of  the  weather  data  collection 
program. 

c.  Backed  up  the  weather  data  to  the  network  drive,  the  PC's  hard  drive  and 
onto  floppy  disk. 
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5.  DATA  PROCESSING. 


The  raw  SFO  data  were  processed  at  the  FAA  Technical  Center  to  reduce  it  to  a 
form  suitable  for  analysis  by  ACD-340  and  AVN-540.  Data  files  generated  in  the 
collection  and  reduction  processes  are  described  in  detail  in  appendix  A.  The 
data  extraction  and  reduction  processes  are  outlined  in  figure  6. 

5.1  DATA  EXTRACTION  AND  REDUCTION. 

5.1.1  Data  Unpacking .  Subsequent  to  data  collection  but  prior  to  data  analysis, 
track  data  were  extracted  from  the  raw  SRAP  and  Interfacility  files  and  merged 
into  a  data  base  consisting  of  parallel  approaches.  The  extraction  procedure, 
unpacking,  was  the  process  whereby  radar  data,  recorded  in  a  foreign  format  for 
purposes  of  space  and  efficiency,  was  converted  to  a  format  compatible  with  the 
analysis  environment.  The  unpacking  process  consisted  of  the  following: 

a.  Raw  SEIAP  and  Interfacility  data  were  converted  to  engineering  units. 

b.  Data  were  sorted  according  to  beacon  code,  aircraft  tracks  with  a 
sufficient  number  of  scans  were  identified,  and  the  runway  being  approached  was 
determined  for  each  track. 

c.  SRAP  and  Interfacility  data  were  cross  referenced  to  obtain  the  aircraft 
ID  and  the  aircraft  type  for  each  track. 

d.  One  record  for  each  track  was  appended  to  the  Master  data  base. 

The  raw  track  files  were  placed  into  a  session  subdirectory,  where  the  session 
was  the  day  of  the  collection  period.  For  a  description  of  the  software  used 
during  unpacking,  see  appendix  B. 

5.1.2  Parrot  Statistics.  The  Parrot  Statistics  test  was  executed  on  the  raw 
SRAP  data  to  assist  in  the  calculation  of  the  radar  range  and  azimuth  biases  for 
a  session.  This  test  was  a  series  of  programs  that  collected,  unpacked, 
analyzed,  and  produced  a  statistical  report  on  the  quantity  and  quality  of 
transponder  data.  The  transponder  data,  collected  continuously  during  each 
session,  was  received  from  the  Oakland  radar  Parrot  transponder  located 
approximately  8  miles  from  the  radar  antenna.  The  report  had  values,  based  on 
the  total  number  of  Parrot  returns,  for  the  mean  and  standard  deviation  of  both 
range  and  azimuth,  and  the  Azimuth  Change  Pulse  (ACP)  skewness  and  kurtosis  of 
the  azimuth.  The  report  (figure  7)  was  compared  with  previous  reports  to 
determine  if  there  had  been  any  change  in  the  radar  range  and  azimuth  biases. 
These  biases  were  computed  and  removed  from  the  raw  track  data  during  the 
translation  to  runway  origin. 

5.1.3  Data  Reduction.  The  reduction  process  took  the  raw  track  files  created 
by  the  unpacking  process  and  performed  the  following  operations  on  them: 

a.  Individual  Track  file  data  were  checked  for  reasonableness;  multiple 
scans  were  deleted,  altitudes  were  added  or  corrected  as  needed,  time  gaps  in 
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FIGURE  6.  DATA  EXTRACTION  AND  REDUCTION  PROCESS 
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Radar  Statistics  using  K:\SP0\UNPAC3C\SC030930.DBF 


»>  PARROT  STATISnCS  FOR  DE3CEMBER  3,  1989  «< 

TbtcLL  number  of  samples  is  9487 

Mean  value  of  RANGE  is  7.201  nmi  (43708  ft) 

Mean  value  of  AGP  count  is  4072.45  (357.93  deg) 
Standard  Deviation  of  RANGE  is  0.006  nmi  (33.6  ft) 
Standard  Deviation  of  ACP  is  0.985  (0.087  deg/1.51  mr) 

or  66.0  ft  @  7.201  nmi 
Die  SkeMness  of  AGP  is  1.386 
Die  Hiirtosis  of  AGP  is  22.230 
Range  of  ACP's  is  fmn  4064  to  4087 
or  357.19  to  359.21  deg 


AGP  CNT 

4064  2 

4065  1 

4066  3 

4067  1 

4068  5 

4069  20 

4070  **  98 

4071  ******************  9S7 

4072  ************************************************************************** 

4073  ********************************************************************  *** 

4074  **************  775 

4075  *  45 

4076  17 

4077  5 

4078  3 

4079  2 

4080  4 

4081  2 

4082  0 

4083  1 

4084  2 

4085  1 

4086  1 

4087  1 

i - 1 - h 

0 


FIGURE  7.  RADAR  STATISTICS  FOR  PARROT  TRANSPONDER 
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in  data  were  identified,  and  pre-  and  post-gap  data  were  checked  to  see  if  they 
were  from  the  same  track. 

b.  Data  were  converted  from  (range,  azimuth,  altitude)  to  cartesian  (x,  y, 
z)  coordinates.  Range  and  Azimuth  biases  were  removed  from  the  track  data. 

c.  Data  were  filtered  and  smoothed  using  Lincoln  Laboratory  developed 
algorithms . 

d.  Interpolated  data  points  were  calculated  at  0.15  nautical  mile  (nmi) 
increments  along  the  extended  runway  centerline. 

The  final  reduced  track  file  consisted  of  reports  at  0.15  nmi  increments  along 
the  extended  runway  centerline.  Each  track  file  record  contained.  Time  -  the 
time  of  day  in  hours,  minutes,  and  seconds,  X  -  distance  from  runway  threshold 
along  the  extended  runway  centerline,  Y  -  deviation  from  extended  runway 
centerline,  and  Z  -  altitude  above  sea  level.  All  fields  were  in  nautical  miles, 
except  time.  The  conversion  factor  was  6076  feet/nmi.  The  file  was  in  reverse 
time  order.  This  meant  that  the  first  record  in  the  file  represented  the 
touchdown  point  or  the  distance  closest  to  touchdown.  Each  successive  record  was 
an  additional  0.15  nmi  from  touchdown  in  the  X  direction.  These  track  files 
were,  in  turn,  individually  plotted  and  then  sent  to  AVN-540  for  further 
analysis.  For  a  description  of  the  software  used  during  reduction,  see 
appendix  B. 

All  track  files  for  each  session  were  plotted  as  a  group  on  a  two-dimensional 
(x,y)  scale  where  x  represents  distance  to  runway  touchdown  and  y  represents 
deviation  about  extended  runway  centerline.  An  example  of  this  type  of  plot  is 
shown  in  figure  8.  The  plots  were  identified  by  the  session  (test)  number, 
runway  designation,  and  the  number  of  track  files  plotted.  A  grid  in  both  axes 
was  superimposed  on  the  plot  so  that  distances  could  be  more  easily  judged.  The 
scale  in  x  was  from  touchdown  to  15  nmi  out.  The  scale  in  y  was  from  -1  to  1 
nmi . 

5.1,4  Master  Data  Base.  A  Master  data  base,  consisting  of  information  about 
each  track  and  the  weather  at  the  time  of  data  collection,  was  produced  through 
the  unpacking  process.  The  Master  data  base  did  not  contain  any  radar  data. 
This  data  base  was  used  to  identify  tracks  for  conditions  that  need  to  be 
analyzed.  For  a  more  detailed  description  of  the  Master  data  base  fields,  see 
appendix  C . 

5 . 2  DELIVERABLES . 

The  requested  track  data  and  their  plots  were  delivered  to  AVN-540.  The  format 
for  sending  the  data  was  floppy  disks.  The  floppy  disks  included  the  final  track 
files  for  each  session  and  the  Master  data  base.  Doctunentation  explaining  the 
data  were  also  sent  along  with  the  plots  created  for  each  session. 


18 


SFO\TRACKSA\SC01 1230.28L\133  TRACKS 


DEVIATION  ABOUT  ILS  (run) 
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FIGURE  8.  EXAMPLE  SESSION  TRACKS  PLOT 


6.  DISCUSSION. 


6.1  DATA  REDUCTION  RESPONSIBILITIES. 


The  Engineering,  Research,  and  Development  Service,  ATC  Technology  Branch 
(ACD-340),  was  tasked  to  collect  and  reduce  track  data  for  aircraft  conducting 
visual  approaches  to  San  Francisco  International  (SFO)  Airport's  runways  28L  and 
28R.  These  data  will  be  used  by  the  AVN-540  to  justify  existing  procedures 
and/or  specify  new  procedures  for  these  approach  operations.  Since  AVN-540  had 
expressed  the  need  to  conduct  their  own  analysis  of  this  data,  ACD-340  did  not 
conduct  any  analysis  for  the  purposes  of  characterizing  the  approaches  in  any  way 
or  validating  the  ability  of  the  sample  tracks  to  navigate  the  approach  routes. 
That  level  of  analysis  was  considered  the  domain  of  AVN-540.  The  type  of 
analysis  provided  by  ACD-340  dealt  with  the  data  on  a  more  universal  level; 
specifically,  what  could  be  said  about  the  validity  of  a  data  sample,  how  well 
did  it  represent  what  really  happened,  and  its  overall  accuracy.  Also  considered 
were  the  most  likely  causes  of  error  in  the  sample  data. 

6.2  DATA  FIDELITY. 

The  data  reduction  process,  as  described  in  section  5  of  this  report,  produced 
a  file  of  position  information  (time,  x,  y,  z)  for  each  recorded  track  where  time 
was  time  of  day,  x  was  the  distance  from  touchdown  along  the  extended  runway 
centerline,  y  was  the  perpendicular  distance  from  the  extended  runway  centerline, 
and  z  was  the  altitude  above  mean  sea  level  (m.s.l.).  These  data  had  been 
filtered,  smoothed  (appendix  A  and  reference  2)  and  interpolated  to  give  a  point 
at  each  0.15  nmi  increment  along  the  extended  runway  centerline.  In  addition, 
since  the  data  were  collected  via  an  air  traffic  control  airport  (ATC)  ASR-7, 
range  and  azimuth  biases  were  removed  as  much  as  possible,  and  the  data  were 
translated  from  range,  azimuth,  and  altitude  with  respect  to  the  radar  antenna 
to  X,  y,  and  z  with  the  origin  at  the  runway  threshold. 

The  final  result  was  a  collection  of  sessions.  A  session  consisted  of  the 
reduced  data  files  for  all  the  tracks  collected  in  a  day.  All  tracks  for  a 
session  were  plotted  on  a  single  graph  and  were  also  subjected  to  a  simple 
statistical  analysis  producing  average  and  standard  deviations  about  the  extended 
runway  centerline  at  increments  of  0.15  nmi  away  from  runway  threshold.  Examples 
of  these  plots  and  statistics  can  be  found  in  the  Data  Reduction  section. 
Details  of  the  procedures  used  to  remove  radar  data  biases  can  also  be  found  in 
that  section. 

In  the  absence  of  any  independent  devices  with  which  to  observe  each  track,  such 
as  a  second  radar,  the  only  way  to  judge  the  validity  of  the  positional 
information  was  to  consider  the  data  at  aircraft  touchdown.  It  was  known  that 
every  aircraft  that  landed,  did  so  on  the  runway  surface.  However,  the  plots  and 
statistics  show  that  the  data  had  a  significant  variance  about  the  runway 
centerline  just  prior  to  runway  touchdown.  On  average,  the  standard  deviation 
at  0.45  nmi  from  touchdown  was  approximately  140  feet.  This  meant  that  many  of 
our  aircraft  appeared  to  be  touching  down  off  the  runway  surface,  on  one  side  or 
the  other.  Two  concerns  needed  to  be  addressed  at  this  point.  The  first  one  was 
why  there  was  such  a  large  variance  near  touchdown.  The  second  involved  what 
this  variance  meant  for  the  data  that  were  not  near  touchdown. 
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6,2.1  Radar  Coverage  Near  Touchdown.  It  was  unfortunate  that  touchdown  was  the 
only  place  where  track  positional  validity  could  be  determined.  This  was  because 
the  radar  was  not  effective  at  seeing  targets  that  were  at  low  altitudes  or  close 
to  the  ground.  Reflections  caused  by  the  ground  produced  erroneous  radar  replies 
and  lowered  the  occurrence  of  primary /beacon  radar  reinforcement.  In  addition, 
the  lower  the  target,  the  more  it  was  missed  by  the  radar. ^  When  coupled  with 
the  relatively  low  ASR-7  scan  rate  of  4.7  seconds  this  meant  that  a  single  bad 
point  close  to  touchdown  could  skew  the  smooth  estimate  of  the  track  at 
touchdown.  The  end  of  the  track,  which  occurred  at  touchdown,  was  a  particularly 
difficult  area  to  smooth  with  high  fidelity  (Thomas  and  Timoteo,  April  1990). 
All  these  factors  gave  rise  to  poor  positional  accuracy  in  the  touchdown  zone. 
It  was,  therefore,  a  bad  point  at  which  to  check  track  positional  validity; 
nevertheless,  as  stated  previously,  it  was  the  only  usable  point. 

Radar  reflections  and  missed  scans  only  partly  addressed  the  large  variance  about 
the  runway  centerline  at  touchdown  however.  There  was  another  factor  that  must 
be  taken  into  consideration  which  not  only  compounded  the  situation  at  touchdown 
but  was  not  limited  to  the  touchdown  zone.  The  target  position  determined  via 
the  beacon  radar  report  was  a  combination  of  range,  azimuth,  and  altitude.  Each 
of  these  measurements  had  the  potential  to  contribute  error  (Thomas  and  Timoteo, 
April  1990) .  Azimuth  error  was  mainly  dependent  on  the  radar  antenna  alignment 
and  wind  loading,  the  Azimuth  Change  Pulse  (AGP)  resolution,  and  the  signal 
strength.  These  were  factors  associated  with  the  radar  and  atmospheric 
conditions.  Altitude  error  was  chiefly  dependent  upon  the  aircraft's  measuring 
system,  since  an  aircraft's  altitude  was  determined  by  its  transponder.  Range 
error,  on  the  other  hand,  was  caused  by  a  combination  of  the  radar  and  the 
aircraft.  This  was  because  the  beacon  range  of  the  target  was  determined  by 
computing  elapsed  time  between  the  start  of  interrogation  by  the  radar  and  the 
receipt  of  the  target  reply  at  the  radar.  At  the  target  the  interrogation  was 
received  via  a  transponder  and,  after  a  definite  time  delay  introduced  by  the 
transponder  (3.0  ±  0.5  /is),  the  reply  was  transmitted  from  aircraft  back  to 
radar.  The  allowable  error  limit  in  the  transponder  turnaround  delay  could  build 
as  much  as  a  ±245 -foot  range  bias  into  the  beacon  range  report.  This  was  larger 
than  the  standard  deviation  of  the  runway  lateral  deviation  error  observed  in  the 
SFO  sample  near  touchdown.  For  information  on  tests  conducted  on  transponder 
delay  error,  the  reader  is  directed  to  Thomas  and  Timoteo,  April  1990. 

The  range  error  became  significant  near  touchdown  at  SFO.  This  was  because  of 
the  orientation  of  radar  with  respect  to  runways  28R  and  28L  (figure  9) .  The 
terminal  radar  used  for  SFO  was  located  at  Oakland  Airport,  approximately  8  miles 
directly  across  the  bay  from  SFO.  This  means  that  error  in  the  measurement  of 
aircraft  lateral  deviation  from  runway  centerline  was  almost  totally  dependent 
on  the  radar  range  error  and  not  on  the  azimuth  error.  Any  azimuth  error  would 
affect  only  the  measurement  of  distance  from  touchdown. 

Taking  the  amount  of  transponder  delay  error  into  consideration  along  with  the 
radar- runway  orientation  at  SFO,  the  magnitude  of  the  random  error  in  the  data 


^In  tests  conducted  at  SFO,  the  radar  could  not  get  replies  from  a  test 
transponder  with  its  antenna  mounted  approximately  20  feet  above  the  end  of 
runway  28R. 


21 


FEET  (Thousands) 


22 


FIGURE  9.  RELATIONSHIP  OF  RUNWAY  AND  RADAR  SITE 


for  SFO  near  touchdown  could  be  considered  reasonable.  It  must  be  remembered 
that  the  error  in  the  range  measurement,  caused  by  the  transponder  delay  error, 
resulted  in  random  error  for  the  data  sample  because  of  the  large  number  of 
transponders  in  the  sample,  one  for  each  aircraft. 

6.2.2  Data  Fidelity  Moving  Away  From  Touchdown.  The  situation  of  SFO  radar 
coverage  at  touchdown  was  unique  due  to  target  altitude  and  radar/runway 
orientation.  SFO  radar  measurement  accuracy  during  the  approach  to  touchdown  was 
different  situation.  The  radar  measurements  on  the  approach  were  not  subject  to 
the  problems  associated  with  low  altitude;  i.e.,  missed  and  reflected  reports, 
since  the  target  was  always  high  enough.  However,  the  measurements  were  still 
subject  to  range  and  azimuth  errors.  Once  again  the  radar/runway  orientation  was 
the  main  factor  because  of  the  requirement  to  determine  how  well  an  aircraft  flew 
its  assigned  approach  course  centerline.  This  course  was  composed  of  a  turn  onto 
the  final  approach,  followed  by  a  straight  line  path  to  touchdown  along  the 
extended  runway  centerline  as  defined  by  the  ILS  localizer  navigation  beam. 
Referring  to  figure  9,  it  can  be  seen  that  the  farther  the  aircraft  was  from 
touchdown  on  the  final  approach  course,  the  deviation  from  course  centerline 
became  more  dependent  on  azimuth  measurement  and  less  dependent  on  range 
measurement.  At  touchdown  this  deviation  was  nearly  all  due  to  range,  at  5  miles 
from  touchdown  the  azimuth  accounted  for  25  percent  of  this  measurement,  and  at 
10  miles  from  touchdown  azimuth  accounted  for  49  percent.  Since  measurement  of 
azimuth  was  not  related  to  the  transponder  delay,  little  random  azimuth  error  was 
expected.  In  tests  performed  using  parrot  transponders  (Thomas  and  Timoteo, 
April  1990),  the  azimuth  had  a  standard  deviation  of  0.13  degrees.  This 
translated  to  a  standard  deviation  of  69  feet  at  5  nmi  and  138  feet  at  10  nmi 
from  the  radar.  Within  limits  the  azimuth  error  would  decrease  the  closer  the 
target  was  to  the  radar.  Since  azimuth  error  was  dependent  chiefly  on  the  radar, 
the  azimuth  bias  was  a  constant  value  and  could  be  removed  from  the  track  data 
during  the  reduction  process. 

6 . 3  SUMMARY . 

In  conclusion,  when  considering  an  aircraft  that  had  turned  onto  and  was  flying 
the  final  approach  at  SFO,  the  collected  radar  data  exhibited  some  error.  The 
error  was  composed  of  both  a  random  (range)  component  and  a  constant  (azimuth) 
component  The  constant  component  was  removed  via  the  parrot  transponder 
procedure  discussed  in  section  5,  but  the  random  component  could  not  be  reliably 
identified  and  removed.  For  the  measurement  of  aircraft  deviation  from  extended 
runway  centerline  (final  approach  centerline),  there  was  less  random  error  the 
farther  the  aircraft  was  from  touchdown.  Therefore,  the  reduced  track  data  would 
exhibit  more  random  error  about  the  extended  runway  cdnterline  at  touchdown  than 
at  any  other  final  approach  point.  A  summary  of  the  percentages  of  deviation 
random  error  versus  fixed  error,  at  2.5  nmi  increments,  is  shown  in  table  1. 
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TABLE  1. 


RUNWAY  CENTERLINE  DEVIATION  ERROR 


Distance  from  Threshold  Random  Error  Fixed  Error 

(along  runway  centerline)  (Range  component)  (Azimuth  component) 


0.0 

77% 

23% 

CM 

98% 

2% 

5.0 

75% 

25% 

7.5 

62% 

38% 

10.0 

51% 

49% 

12.5 

45% 

55% 

15.0 

39% 

61% 

7.  PROJECT  SCHEDULE  AND  MILESTONES. 


SFO  data  collection  was  originally  planned  to  be  completed  by  December  1989; 
however,  AVN-540  requested  additional  data  collection  up  through  March  1990.  In 
October  1990,  AVN-540  perceived  a  need  for  additional  data  and  requested  that  all 
remaining  data  be  processed  and  sent  out  to  them.  These  additional  and  unforseen 
requests  necessitated  that  the  planned  completion  dates  for  data  delivery  to  AVN- 
540  and  the  Final  Report  Technical  Note  be  pushed  back. 


MILESTONE 

a.  Complete  Software  Modifications  to  the  DUALSRAP 

Data  Collection  System. 

b.  Complete  System  Integration  Testing  of  New 

Modifications . 

c.  Perform  Optimization  Tests  at  San  Francisco. 

d.  Start  Data  Collection  for  San  Francisco. 

e.  End  Data  Collection  for  San  Francisco. 

f.  Final  delivery  of  Data  Base  and  Plots  to  AVN-540 

(SFO) . 

g.  Publish  Technical  Note  on  SFO  results. 


COMPLETION  DATE 

10/89 

10/89 

10/89 

11/89 

03/90 

03/91 

01/92 
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LIST  OF  ACRONYMS 


ACP  Azimuth  Change  Pulse 

ARTS  Automated  Radar  Terminal  System 

ASR  Airport  Surveillance  Radar 

ATC  Air  Traffic  Control 

ATCBI  Air  Traffic  Control  Beacon  Interogator 

ATIS  Automatic  Terminal  Information  Service 

BDAS  Beacon  Data  Acquisition  System 

DASI  Digital  Altimeter  System  Indicator 

DOS  Disk  Operating  System 

EBL  Extended  Batch  Language 

FAA  Federal  Aviation  Administration 

ID-DAS  Identification  Data  Acquisition  System 

IDSM  Interfacility  Data  System  Microprocessor 
IFR  Instrument  Flight  Rules 

ILS  Instrument  Landing  System 

I/O  Input/Output 

IRIG  Inter  Range  Instrumentation  Group 

m.s.l.  Mean  Sea  Level 

NAS  National  Airspace  System 

NBS  National  Bureau  of  Standards 

nmi  Nautical  Miles 

NOZ  Normal  Operating  Zone 

NWS  National  Weather  Service 

PC  Personal  Computer 

PIM  Peripheral  Interface  Module 

RDAS  Radar  Data  Acquisition  System 

RML-6  Radar  Microwave  Link 

SA  Surface  Weather  Observation 

SFO  San  Francisco  International  Airport 

SP  Special  Report 

SPI  Special  Position  Indicator 

SRAP  Sensor  Receivor  and  Processor 

TRACON  Terminal  Radar  Approach  Control  Facility 
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APPENDIX  A 


DATA  FILES 

Two  types  of  data  files  are  described  in  this  appendix.  Raw  data  files  consist 
of  data  collected  in  the  field,  both  at  San  Francisco  International  Airport  (SFO) 
and  at  the  FAA  Technical  Center.  Reduced  data  files  consist  of  data  that  has 
been  converted  to  a  format  compatible  with  the  analysis  environment. 

A.l  RAW  DATA  FILES. 

Raw  Sensor  Receiver  and  Processor  (SRAP),  Interfacility,  and  Digital  Altimeter 
Setting  Indicator  (DASI)  data  were  collected  on-site  at  SFO.  Raw  weather  data 
were  collected  at  the  FAA  Technical  Center.  The  following  is  a  description  of 
the  raw  data  files  created  at  the  time  of  field  collection. 

A. 1.1  SRAP. 

The  raw  SRAP  data  were  recorded  onto  disk  using  the  filename  format  Smddhhmm.DAT: 
where:  S  -  the  letter  "S” 

m  -  the  month  (1  thru  9,  A  for  October,  B  for  November,  and 
C  for  December) 

dd  -  day  of  month-2  digits  (01  to  31) 
hh  -  hour  of  start  of  test  (00  to  23) 
mm  -  minute  of  start  of  test  (00  to  59) 

From  the  raw  SRAP  file  the  following  data  were  extracted: 

a.  Time  in  hours,  minutes,  seconds  referenced  to  SFO  (Pacific  time  zone) 

b.  Radar  sector  number 

c.  SRAP  channel  number  (0) 

d.  Slant  range  in  nmi  from  radar 

e.  Azimuth  Change  Pulse  (ACP)  (0  thru  4096) 

f.  Azimuth  in  degrees 

g.  Quality  (0  thru  7) 

h.  Special  Position  Indicator  (SPI)  (not  used) 

i.  Beacon  code  (0000  thru  7777) 

j .  Beacon  code  validity  (0  thru  3) 

k.  Altitude  in  hundreds  of  feet  (uncorrected) 
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l.  Altitude  validity  (0  thru  3) 

m.  Beacon  hit  count 


n.  Message  type  (BO  for  beacon  only,  RB  for  radar  reinforced  beacon) 

A. 1.2  INTERFACILITY. 

The  interfacility  data  was  recorded  onto  disk  using  the  filename  format 
Imddhhmm.AOL  (for  more  information  on  "mddhhmm" ,  see  A. 1.1).  The  interfacility 
data  file  contained  the  following  data: 

a.  ARR  (arrival) 

b.  Time  in  hours  and  minutes  with  respect  to  SFO 

c.  Beacon  code  (0000  thru  7777) 

d.  ACID  (e.g. ,  UAL923) 

e.  ACTYPE  (e.g. ,  B737) 

f.  Approach  fix  (e.g.,  JOT) 

g.  Altitude  at  fix  in  hundreds  of  feet  (e.g.,  100  for  10,000  feet) 

A.i.3  DASI. 

DASI  data  were  recorded  onto  disk  using  the  filename  format  Smddhhmm.RCM  (for 
more  information  on  Smddhhmm,  see  A. 1.1). 


A. 1.4  WEATHER. 

The  raw  weather  data  were  collected  on  an  FAA  Technical  Center  computer  by 
logging  on  the  Kavouris  Inc.  weather  data  base  and  requesting  the  day's  weather 
reports  for  SFO.  The  data  were  recorded  onto  a  disk  file  whose  name  had  the 
format  WXmmddy y . TXT : 

where;  WX  -  the  letters  "WX" 

mm  -  the  month  -  2  digits  (01  thru  12) 
dd  -  day  of  month  -  2  digits  (01  to  31) 
yy  ”  year  -  2  digits  (00  to  99) 

V  »l  M 

TXT  -  the  letters  "TXT" 


The  weather  file  consisted  of  weather  reports,  each  report  containing  the 
following  data; 


a.  Date  in  month/day/year 

b.  Time  in  hours  and  minutes  (Zulu) 

c.  Location  (SFO) 
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d.  Report  type  (SA  or  SP  or  RS) 

e.  Lowest  ceiling  type  (E  or  M  or  W) 

f.  Lowest  ceiling  height  in  hundreds  of  feet 

g.  Lowest  sky  descriptor  (OVC  or  CLR  or  BKN  or  ...) 

h.  Next  lowest  ceiling  type  (E  or  M  or  W) 

i.  Next  lowest  ceiling  height  in  hundreds  of  feet 

j .  Next  lowest  sky  descriptor  (OVC  or  CLR  or  BKN  or  . . . ) 

k.  Visibility  in  nmi 

l.  Weather  (rain  or  fog  or  snow  or  ...) 

m.  Sea  level  pressure  in  millibars 

n.  Temperature  in  degrees  fahrenheit 

o.  Dewpoint  in  degrees  fahrenheit 

p.  Wind  direction  in  tens  of  degrees  referenced  to  true  north 

q.  Wind  speed  in  knots 

r.  Wind  gust  in  knots 

s.  Altimeter  setting  in  inches  of  mercury 

t.  Remarks 

Note:  for  more  information  on  this  data  refer  to  the  Aviation  Weather  Services 
Manual,  AC  00-45B  published,  jointly  by  FAA  and  National  Oceanic  and  Atmospheric 
Administration  (NOAA) . 

A, 2  DATA  REDUCTION  FILES. 

Raw  SEIAP,  Interfacility,  DASI ,  and  weather  data  files  were  unpacked  and  reduced 
at  the  FAA  Technical  Center.  The  following  is  a  description  of  the  Data 
Reduction  files  created  from  the  raw  data  files. 

A. 2.1  DATA  REDUCTION  TRACK  FILES. 

The  track  files  created  during  the  reduction  process  consisted  of  all  the 
position  reports  for  a  single  aircraft's  approach.  The  type  and  format  of  the 
information  contained  in  each  track  file  type  is  listed  below. 

FILENAME  — >  MEANING 
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_acid.rwy  -=> 
DATA: 

(aacid.rwy  =-=> 
DATA: 

$acid.rwy  — > 
DATA: 

&acid.rwy  — > 
DATA: 

'acid.rwy  --> 
DATA: 

(acid.rwy  ■==> 
DATA: 


raw  track  file  (SRAP  0)  (output  of  TRACKS) 

HR , MN , SEC , CH , RANGE . AZMTH , BC , ALT , TYPE 

corrected  track  file  (SRAP  0)  (output  of  GAP) 

HR , MN , SEC , CH , RANGE , AZMTH , BC , ALT , TYPE 

GAP  documentation  file  (SRAP  0) 

list  of  missing  scans  and  altitudes,  and  multiple  scans 

translated  to  runway,  corrected  track  file  (SRAP  0)  (output 
of  PTTRANS) 

HR.MN,SEC,X,Y,Z 

smoothed,  translated,  corrected  track  file  (SRAP  0)  (output 
of  SM) 

HR,MN,SEC,X,Y,Z 

interpolated,  smoothed,  translated,  corrected  track  file 
(SRAP  0)  (output  of  INTERP) 

HR,MN,SEC,X,Y,Z 


where:  acid  -->  aircraft  ID  (AAL1115,  UALIOO,  ...) 

rwy  “>  runway  designator  (  28L,  28R,  ...) 

A.2.2  DATA  REDUCTION  INTERFACILITY  FILES. 

The  interfacility  data  files  created  during  the  reduction  process  consisted  of 
the  data  present  in  the  raw  interfacility  data  file,  however,  these  file  data 
were  converted  to  a  Foxbase  data  base  format. 


Imddhhmm.DBF  —>  Interfacility  data  in  a  Foxbase  data  base  format 
DATA:  (see  Appendix  A. 1.2) 

A. 2. 3  DATA  REDUCTION  DAS I  FILES. 

The  DASI  data  files  created  during  the  reduction  process  consisted  of  DASI  data 
extracted  from  the  raw  DASI  data  files.  The  reduced  data  files  were  converted 
to  Foxbase  data  base  format. 

Rmddhhmm.DBF  — >  DASI  data  in  a  Foxbase  data  base  format 

DATA:  Digital  Altimeter  Setting  Indicator  (DASI) 

A. 2. 4  DATA  REDUCTION  WEATHER  FILES. 

The  weather  data  files  created  during  the  reduction  process  consisted  of  the  data 
present  in  the  raw  weather  data  files.  The  reduced  data  files  were  converted  to 
a  Foxbase  data  base  format  and  merged  with  the  MASTER  data  base  (see  Appendix  C)  . 

WXmmddyy.FIX  -— >  preprocessed  and  corrected  weather  data  file 

DATA:  (see  Appendix  A. 1.4) 
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WXininddyy .  DAT  “> 
DATA: 

SFOnunin .  DAT 


weather  data  for  1  day  in  Foxbase  data  base  compatible 
format 

(see  Appendix  A. 1.4) 

weather  data  for  1  month  (mmm  -  Jan,  Feb,  etc.) 
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DATA  REDUCTION 

The  data  collected  at  the  site  was  brought  back  to  the  FAA  Technical  Center  where 
it  was  reduced  to  a  form  to  be  used  in  the  final  analysis.  Unpacking  was  the 
process  whereby  data,  recorded  in  a  foreign  format  for  purposes  of  space  and 
efficiency,  was  converted  to  a  format  compatible  with  the  analysis  environment. 
Reduction  was  the  process  of  coordinate  conversion,  filtering,  smoothing,  and 
interpolation  of  the  unpacked  radar  data.  Each  of  the  raw  data  files  identified 
in  Appendix  A  had  to  be  unpacked.  The  unpacking  and  reduction  procedures  are 
described  here. 

B.l  SRAP  AND  INTERFACILITY  DATA. 

The  radar  data  collected  via  the  Sensor  Receiver  and  Processor  (SRAP)  required 
considerably  more  processing  than  any  other  type  of  data  collected  to  prepare  it 
for  analysis.  Unpacking  and  reduction  of  the  radar  data  Involved: 

a.  Conversion  to  engineering  units  and  sorted  according  to  beacon  code. 

b.  Deletion  from  further  processing  if  any  of  the  following  were  detected; 
large  gap(s)  in  the  track,  track  was  of  short  duration  or  no  Mode  C  altitude  and 
altitude  can't  be  had  from  other  sources. 

c.  Conversion  to  (time,  x,y,z),  then  translation  and  rotation  to  the  runway 
threshold  being  approached. 

d.  Filtering  and  smoothing  of  radar  data  to  eliminate  radar  outliers  and 
to  obtain  a  more  accurate  estimate  of  aircraft  position. 

e.  Interpolation  to  attain  estimates  of  cross-track  deviation  at  specific 
points  along  the  Instrument  Landing  System  (ILS)  approach. 

The  following  software  programs  performed  these  processes  on  the  raw  SRAP  data 
with  the  following  results. 

B ■ 1 ■ 1  TRACKS . FOX . 

-->  language:  Foxbase  +2.10  programming  language 

- ->  input:  a.  Smddhhmm.DAT  (raw  SRAP  data  file) 

b.  Imddhhmm.AOL  (raw  Interfacility  data  file) 

- ->  process:  a.  Invoked  SRAPUNPK.PAS  to  unpack  raw  SRAP  data  and 

produced  SRAP  foxbase  database  file  Smddhhmm.DBF 

b.  Indexed  Smddhhmm.DBF  by  session  and  beacon  code 

c.  Identified  tracks  with  sufficient  number  of  scans 

d.  Determined  runway  being  approached  for  each  track 

e.  Cross  referenced  SRAP  data  with  interfacility  data  file 

Imddhhmm.AOL  to  obtain  aircraft  ID  (ACID)  and 
aircraft  type  (ACTYPE)  for  each  beacon  code 
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-->  output: 


B.1.2  SRAPUNPK.PAS. 
- ->  language : 
-->  input: 

-->  process: 

-->  output: 

B. 1 ■ 3  GAP.C. 

-->  language: 
-->  inputs: 

- ->  process : 


- ->  outputs : 

B ■ 1 ■ 4  PTTRANS , C . 
-->  language: 
- ->  inputs: 

- ->  process : 

- ->  outputs : 


f.  Appended  a  record  to  the  master  data  base  (MASTER. DBF) 
for  each  identified  track  (see  Appendix  C) 

a.  Created  directory  “Smddhhmm"  and  placed  ASCII  aircraft 

track  files  _acid.RWY  for  SRAPO  into  this  directory 
(see  Appendix  A. 2) 

b.  Appended  one  record  for  each  identified  track  to  the 

MASTER  database  (see  Appendix  C) 


Turbo  PASCAL  5.0 

Smddhhmm.DAT  (raw  SRAP  data  file) 

Unpacked  beacon  and  radar  reinforced  beacon  messages  only 
Smddhhmm. DBF  (Foxbase  database  format) 


Turbo  C  2.0 

a.  All  _acid.rwy  files  (raw  track  files) 

b.  MASTER. DBF  master  data  base  (optional,  depended  on 

version  of  GAP.C) 

a.  Deleted  illegal  multiple  scans 

b.  Added  missed  altitudes 

c.  Altitude  correction  based  on  airport  altimeter  setting 

d.  Identified  large  time  gaps  and  determined  if  the  pre-gap 

and  post -gap  data  is  from  the  same  track 

e.  Produced  documentation  explaining  results 

(Sacid.rwy  (SEIAPO)  corrected  track  files  (Appendix  A. 2.1) 
$acid.rwy  (SRAPO)  documentation  files  (Appendix  A. 2.1) 


Turbo  C  2.0 

All  @acid.rwy  files  (corrected  track  files) 

a.  Converted  data  from  (rng,az,alt)  to  (x,y,z) 

b.  Translated  data  to  runway  threshold  identified  in 

filename 

&acid.rwy  (SRAPO)  translated  and  corrected  track  files 
(Appendix  A. 2.1) 
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-->  language:  Turbo  C  2.0 


-->  inputs:  All  &acid.rwy  files  (translated  and  corrected  track  files) 

-->  process:  Filtered  and  smoothed  using  Lincoln  Lab's  radar  smoothing 

algorithms 

-->  outputs:  'acid.rwy  (SRAPO)  filtered,  smoothed,  translated,  and 

corrected  track  files  (Appendix  A. 2.1) 

B.1.6  SPLINE. C. 

-->  language:  Turbo  C  2.0 

- ->  inputs:  All  'acid.rwy  files  (filtered,  smoothed,  translated,  and 

corrected  track  files) 

-->  process:  Inserted  an  interpolated  data  point  (time,x,y,z)  at  each 

0.15  mile  X  increment 

-->  outputs:  (acid.rwy  (SRAPO)  interpolated,  filtered,  smoothed, 

translated,  and  corrected  track  files  (Appendix  A. 2.1) 

B.2  PAST  DATA. 

The  raw  DASI  data  was  processed  by  the  following  program  with  the  described 
results . 

B.2.1  RCMSUPK.PAS. 

-->  language:  Turbo  Pascal  5.0 

- ->  inputs:  Smddhhmm.RCM  (raw  ROMS  data  file) 

- ->  process:  Unpacked  DASI  data  and  put  it  into  a  Foxbase  data  base 

format 

-->  outputs:  Rmddhhmm.DBF  (unpacked  DASI  data  in  Foxbase  format) 

B.3  WEATHER  DATA. 

The  weather  data  for  San  Francisco  International  Airport  (SFO)  required  some 
preprocessing  before  it  could  be  unpacked  by  the  weather  data  unpacking  program, 
SFOWX.BAS.  The  weather  data  preprocessing  and  unpacking  procedures  are  described 
here . 
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Preprocessing  a  weather  data  file  consisted  of: 

a.  Removed  correction  weather  reports  and  blank  lines  between  weather 
reports . 

b.  Added,  if  necessary,  a  ")"  to  the  end  of  the  weather  data  file  as  an  End 
of  File  marker  (EOF). 

c.  Checked  that  the  first  line  of  each  weather  report  had  at  least  one  "/" 
in  it.  SFOWX.BAS  needed  at  least  one  "/"  in  the  first  line  of  a  weather  report 
to  process  that  report  properly. 

Unpacking  the  preprocessed  weather  data  files  created  one  Foxbase  database 
compatible  file  for  each  day  and  one  Foxbase  database  compatible  file  for  each 
month  of  weather  data  files. 


B.3.1  CORRECT .BAS. 
-->  language; 

- ->  input; 

- ->  process ; 


- ->  output : 

B.3.2  SLASH .BAS. 
-->  language; 
-->  input: 

- ->  process : 

- ->  output: 

B.3.3  SFOWX.BAS 

-->  language: 
-->  input: 

-->  process: 


Turbo  BASIC  1.0 

WXmmddyy.TXT  (raw  weather  data  file) 

a.  Kept  last  correction  weather  repo  t  in  data  file,  all 

previous  correction  reports  and  the  original  report 
were  removed  from  the  weather  data  file 

b.  Removed  blank  lines  between  weather  reports  in  a  file 

c.  Added,  if  needed,  a  ")"  to  the  weather  data  file  as  an 

EOF  marker 

WXmmddyy.FIX  (corrected  weather  data  files) 


Turbo  BASIC  1.0 

WXmmddyy.FIX  (corrected  weather  data  file) 

Counted  number  of  "/"  in  first  line  of  each  weather  report 

WXmrayy.BAD  (listing  by  time  for  each  ".FIX"  file  of  weather 
reports  with  less  than  five  "/"  in  their  first  line) 


Turbo  BASIC  1.0 

WXmmddyy.FIX  (corrected  weather  data  file) 

Unpacked  a  weather  data  file  to  produce  a  Foxbase  database 
compatible  record  for  each  weather  report  and  reordered 
records  by  time  and  date  in  ascending  order  in  the  output 
files 


-->  outputs:  WXmmddyy . DAT  (unpacked  weather  data  file) 

SFOmmm.TOT  (combined  WXmmddyy . DAT  files  for  1  month,  where 
mmm  -  JAN,  FEB,  MAR,  etc.) 

B.3.4  STRU.DBF. 

-->  language:  Foxbase  +  2.10  programming  language 

-->  input:  SFOmmm.TOT  (combined  WXmmddyy.DAT  files) 

-->  process:  STRU.DBF  was  a  database  structure  with  fields  for  the  data 

contained  in  a  weather  report,  it  was  copied  to 
WX_mmm.DBF.  The  data  in  the  SFOmmm.TOT  file  was  then 
added  to  WX_mmm.DBF  using  the  Foxbase  APPEND  command. 

-->  output:  WX_mmm.DBF  (weather  data  for  one  month  in  Foxbase  database 

format) 

Certain  weather  database  fields  were  next  merged  with  the  Master  Database  (see 
Appendix  C) . 

B.A  PARROT  TRANSPONDER  DATA. 

Parrot  data  statistics  were  extracted  from  the  raw  SRAP  data,  to  assist  in  the 
calculation  of  the  radar  range  and  azimuth  biases,  using  the  program  described 
below. 

B.4.1  TC_PAR0T.F0X. 

-->  language:  Foxbase  +  2.10  programming  language 

-->  input:  Smddhhmm.DBF  (Foxbase  database  format) 

-->  process:  Collected,  unpacked,  analyzed,  and  produced  a  statistical 

report  on  the  quantity  and  quality  of  the  Parrot 
transponder  data 

-->  output:  A  printout  of  a  report  containing  values  for  the  mean  and 

standard  deviation  of  both  range  and  azimuth,  and  the  ACP 
skewness  and  kurtosis  of  the  azimuth 
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MASTER  DATA  BASE 

Prior  to  data  analysis  all  unpacked  data  was  merged  into  a  data  base  that 
identified  each  approach  collected.  This  data  base  was  referred  to  as  the  MASTER 
data  base.  Data  used  to  construct  the  MASTER  data  base  consisted  of  information 
about  each  track  and  the  weather  at  the  time  of  the  track's  collection.  The 
MASTER  data  base  did  not  contain  the  tracks'  radar  position  data  however.  The 
radar  position  data  for  each  track  was  instead  stored  in  the  individual  track 
files  (refer  to  Appendix  A. 2.1). 

The  MASTER  data  base  contained  one  record  for  each  approach.  The  record  had  a 
field  for  each  track  characteristic.  Since  the  format  of  the  MASTER  data 
base  was  developed  for  an  earlier  data  collection  effort,  there  were  some  fields 
in  the  data  base  not  used  for  the  San  Francisco  International  Airport  (SFO)  data 
collection  effort. 

C.l  MASTER  DATA  BASE  FIELDS. 

The  MASTER  data  base  record  fields  are  shown  on  a  single  page  in  figure  C.l. 
C.2  MASTER  DATA  BASE  GENERATION. 

The  MASTER  data  base  (_MASTER. DBF)  was  generated  in  a  multi-step  process.  Only 
the  following  fields  were  used  in  the  SFO  data  collection. 

Field  Description 

1  test  or  session  name  (eg.  S2131453) 

2  SRAP  channel  #  (0  or  1) 

3  aircraft  ID  (eg.  UAL9253) , 

4  user  type  (Military,  Commercial,...) 

5  aircraft  type  (eg.  B727) 

6  beacon  code  (0000  thru  7777) 

7  month/day/year  of  collection 

8  time  of  day  of  first  scan  for  the  track 

9  time  of  day  of  last  scan  for  the  track 

10  altitude  of  first  scan  for  the  track 

11  altitude  of  last  scan  for  the  track 

12  number  of  scans  for  the  track 

13  runway  being  approached 

28  temperature  in  degrees  fahrenheit  during  track 

29  dewpoint  in  degrees  fahrenheit  during  track 

30  ceiling  type  (M  or  E  or  W) 

31  ceiling  height  in  feet 

32  visibility  in  nautical  miles 

33  weather  (Fog  and/or  Rain  and/or  Snow,...) 

34  wind  speed  in  knots 

35  wind  direction  in  degrees  from  true  north 

42  barometric  pressure  in  inches  of  mercury 

43  X  at  which  A/C  is  stabilized  on  localizer 
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Field  Name  Type  Lnth  Description 

1  SESSION  Chr  8  test  name  (e.g.,  S2131453)  (see  Appendix  A, 1.1) 

2  CH  Num  1  channel  #  (0  or  1)  of  SRAP 

3  AC_ID  Chr  7  aircraft  ID  (e.g.,  UAL9253) 

4  USER_TYPE  Chr  1  user  type  (Military  or  Commercial  or  ...) 

5  AC_TYPE  Chr  5  aircraft  type  (e.g.,  B727) 

6  BEACON  Chr  4  beacon  code  (0000  thru  7777) 

7  DATE  Date  8  month/day/year  of  collection 

8  START_TIME  Chr  11  time  of  day  of  first  scan  for  the  track 

9  ST0P_TIME  Chr  11  time  of  day  of  last  scan  for  the  track 

10  START_ALT  Num  6  altitude  of  first  scan  for  the  track 

11  ST0P_ALT  Num  6  altitude  of  last  scan  for  the  track 

12  TARGET_CT  Num  4  number  of  scans  for  the  track 

13  RUNWAY  Chr  3  runway  being  approached 

14  MIN_X  Num  8  minimum  distance  from  threshold 

15  T_AT_4_NMI  Chr  11  time  of  day  at  4  nmi  from  threshold 

16  MAX_Y_TNTZ  Num  6  maximum  lateral  deviation  from  ILS  towards  NTZ 

17  XMAXY_TNTZ  Num  8  distance  from  threshold  at  MAX_Y_TNTZ 

18  MAX_Y_ANTZ  Num  6  maximum  lateral  deviation  from  ILS  away  from  NTZ 

19  XMAXY_ANTZ  Num  8  distance  from  threshold  at  MAX_Y_ANTZ 

20  MAX_Z  Num  6  maximum  altitude  for  the  track 

21  MIN_Z  Num  6  minimum  altitude  for  the  track 

22  MEAN_Y  Num  6  average  ILS  deviation  from  stabilization  to  TD 

23  MEAN_XD0T  Num  8  average  velocity  of  A/C  during  ILS  approach 

24  STD_DEV_Y  Num  6  standard  deviation  of  ILS  lateral  deviation 

25  IN_NTZ  Log  1  .TRUE,  if  A/C  in  NTZ  after  stabilization 

26  NTZ_DIS  Num  6  width  of  NOZ  in  feet 

27  X_AT_VI0  Num  8  distance  from  threshold  at  first  NTZ  violation 

28  TEMP  Num  3  temperature  in  degrees  fahrenheit  during  track 

29  DEWPT  Num  3  dewpoint  in  degrees  fahrenheit  during  track 

30  CEIL_TYPE  Chr  1  ceiling  type  (M  or  E  or  W) 

31  CEILING  Num  5  ceiling  height  in  feet 

32  VISIBILITY  Num  5  visibility  in  nautical  miles 

33  WEATHER  Chr  4  (Fog  and/or  Rain  and/or  Snow  and/or  ...) 

34  WIND_SPEED  Num  2  wind  speed  in  knots 

35  WIND_DIR  Num  3  wind  direction  in  degrees  from  true  north 

36  LLWAS_SPD  Num  2  low  level  windshear  alert  system  speed  in  knots 

37  LLWAS_DIR  Num  3  low  level  windshear  alert  system  direction  deg. 

38  LLWAS_GUST  Num  2  low  level  windshear  alert  system  gusts  in  knots 

39  CFA_SPD  Num  2  low  level  windshear  alert  system  center  field  ws 

40  CFA_DIR  Num  3  low  level  windshear  alert  system  center  field  wd 

41  RVR  Num  4  runway  visual  range  in  feet 

42  BRMTR  Num  5  barometric  pressure  in  inches  of  mercury 

43  STBL_X  Num  5  X  at  which  A/C  is  stabilized  on  localizer 

44  PAIR_LDR  Chr  7  leading  adjacent  localizer  AC_ID  (if  it  exists) 

45  PAIR_TRL  Chr  7  trailing  adjacent  localizer  AC_ID  (if  it  exists) 

46  GAP_START  Chr  11  raw  track  file  start  time  (as  determined  by  GAP) 

47  GAP_ST0P  Chr  11  raw  track  file  stop  time  (as  determined  by  GAP) 

48  GAP_STRT_R  Num  6  raw  track  file  initial  range 

49  GAP_ST0P_R  Num  6  raw  track  file  final  range 

50  GAP_NUM  Num  3  number  of  scans  in  raw  track  file 

51  GAP_MS_SCN  Num  3  number  of  missing  scans  in  raw  track  file 

52  GAP_D0UBLE  Num  3  number  of  double  scans  in  raw  track  file 

53  GAP_ALT  Num  3  number  of  missing  or  unreasonable  altitudes 

total  of  282  bytes/record. 
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MASTER  DATA  BASE  RECORD  STRUCTURE 


The  processes  that  generated  the  MASTER  database  are  identified  and  described 
in  the  following: 

C ■ 2 ■ 1  TRACKS ■ FOX . 

TRACKS . FOX  was  the  same  process  identified  and  partially  described  in  Appendix 

B. 1.1.  In  addition  to  the  identification  and  unpacking  of  the  individual 
track  files,  it  also  appended  one  record  to  the  MASTER  data  base  for  each 
track.  TRACKS . FOX  filled  in  data  fields  1  through  13;  (1)  session,  (2) 
channel,  (3)  ACID,  (4)  user-type,  (5)  AC-type,  (6)  beacon  code,  (7)  date,  (8) 
start  time,  (9)  stop  time,  (10)  start  altitude,  (11)  stop  altitude,  (12) 
target  count,  and  (13)  runway  for  each  aircraft  track. 

C .  2 . 2  WXAPP ■ FOX . 

This  process  appended  fields  (28)  temperature,  (29)  dewpoint,  (30)  ceil_type, 
(31)  ceiling,  (32)  visibility,  (33)  weather,  (34)  wind  speed,  (35)  wind 
direction,  and  (42)  barometer  pressure  by  time  and  date  to  records  in  the 
MASTER  data  base. 

- ->  input:  WX_mmm.DBF  (weather  database  files,  see  Appendix  B.3.4) 

-->  process:  Merged  fields  from  weather  data  base  with  the  appropriate 

fields  in  the  MASTER  data  base 

- output:  Modified  MASTER  database  weather  fields  cited  above 

C . 2 . 3  STABLE_X . 

STBL_X  (43)  was  the  distance  from  the  end  of  the  runway  on  the  X  axis  at  which 
the  approaching  aircraft  is  considered  stabilized  on  the  localizer.  This 
value  was  not  calculated  for  SFO  tracks.  However,  a  value  was  needed  in  this 
field  to  run  the  analysis  software;  for  this  purpose,  a  value  of  4  nmi  was 
used. 
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SFO  DATA  COLLECTION  REFERENCE  MA>RJAL 
D.l  SRAP  DATA  COLLECTION. 

The  automatic  Sensor  Receiver  and  Processor  (SRAP)  data  collection  software  ran 
at  the  Bay  Terminal  Radar  Approach  Control  (TRACON)  in  support  of  the  Visual 
Approaches  Data  Collection  Project  (F20-06G) .  The  data  collection  software 
consisted  of  various  programs  invoked  by  a  batch  file  on  the  SRAP  data  collection 
computer  (XT).  The  batch  file,  RUN_SFO.BAT,  was  initiated  by  an  appointment 
scheduling  program  each  day  at  0600  (Pacific  time) .  The  batch  program  initiated 
the  following  steps. 

D.1.1  BATCH  FILE  CREATION. 

RUN_CrO.BAT  initiated  MAKE_BAT . PRG .  MAKE_BAT.PRG  was  an  ACD-340  written  Foxbase 
program  which  created  three  batch  files  (FILENAMD.BAT,  ARC_REST.BAT,  and 
DELE_CHK.BAT).  These  files  renamed,  set  file  attributes,  and  deleted  the  data 
collection  files  at  the  appropriate  times.  The  filenames  nreatod  by  MAKE_BAT . PRG 
were  based  on  the  current  date  and  time  of  day  in  order  to  uniquely  identify  the 
daily  SRAP  data  collection  files.  For  more  information  on  these  batch  files  see 
Appendices  D.l. 3,  D.1.4.2,  and  D. 1.4.4. 

D.1.2  DATA  COLLECTION  PROGRAM. 

FASTSRAP.EXE  was  an  ACD-340  written  80S8  assembly  language  program  which 
collected  and  stored  SRAP,  DASI,  and  message  data  (SRAP.DAT,  RCMS.DAT,  and 
MESS.DAT)  to  the  C:\DATA  subdirectory.  For  more  information  on  the  SRAP  and  DASI 
data  files  see  Appendices  A. 1.1  and  A. 1.3.  The  message  data  file  was  a  listing 
of  messages  generated  by  FASTSRAP.EXE  during  execution.  These  messages  were  not 
used  during  the  data  analysis.  FASTSRAP.EXE  ran  from  whenever  it  was  started  to 
2200  hours. 

D.1.3  FILE  TRANSFER. 

FILENAME.BAT  renamed  the  SRAP,  DASI,  and  message  data  files,  created  by 
FASTSRAP.EXE,  to  Smddhhmm.DAT,  Smddhhmra . RCM ,  and  Smddhhmra.MES  respectively  (for 
more  information  on  "mddhhmm"  see  Appendix  A. 1.1  ).  FILENAME.BAT  then  checked 
that  the  network  was  up,  if  so,  then  it  copied  the  renamed  SRAP,  DASI,  and 
message  data  files  to  the  J:\  directory. 

D.1.4  FILE  BACKUP. 

The  file  backup  process  consisted  of  a  Primary  backup,  setting  the  archive  bit 
of  the  day's  collected  SRAP  data  files,  and  a  secondary  backup  .  After  this,  the 
SRAP  data  files  were  deleted  from  the  C:\DATA  subdirectory  only  if  they  were 
successfully  copied  to  the  network  J;  drive  when  FILENAME.BAT  executed. 
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D. 1.4.1  Primary  Backup. 

PRIMARY.BAT  performed  a  primary  tape  backup  of  the  SRAP  data  files  in  the  C:\DATA 
subdirectory  which  had  not  been  backed  up  previously;  i.e.  those  files  that  had 
their  archive  bit  set.  The  primary  tape's  subdirectory  was  then  stored  in  the 
C:\DATA\BACKUP  subdirectory  as  TArCDIRl . TXT . 

D.1.4.2  Setting  Archive  Bits. 

ARC_REST.BAT  set  the  archive  bit  of  the  SRAP  data  files  collected  that  day.  The 
archive  bit  was  used  as  a  flag  during  the  secondary  tape  back  up  to  ensure  that 
only  these  files  were  saved. 

D.1.4.3  Secondary  Tape  Back  Up . 

SECONDRY.BAT  backed  up  on  to  the  secondary  tape  drive  the  SRAP  data  files  saved 
during  the  primary  back  up.  The  full  secondary  tape's  directory  was  then  stored 
in  C:\DATA\BACKUP  subdirectory  as  TAPED1R2.TXT. 

D. 1.4.4  Deletion  of  SRAP  Data  Files  on  C:\DATA . 

DELE_CHK.BAT  checked  that  the  day's  SRAP  data  files  were  successfully  copied  to 
the  J ;  drive  (see  Appendix  D.1.3).  If  the  files  existed  on  J ;  then  DELE_CHK.BAT 
went  ahead  and  deleted  the  files  from  the  C:\DATA  subdirectory. 

D.2  INTERFACILITY  DATA  COLLECTION. 

The  following  is  an  explanation  of  the  Landrum  &  Brown  (L&B)  ARTS  IDentif ication 
Data  Acquisition  System  (ID-DAS)  ran  at  the  Bay  TRACON.  This  process  was  invoked 
by  ISFO_RUN.BAT  on  the  Interfacility  data  collection  computer  (IQ-Plus  XT 
compatible).  ISFO_RUN.BAT  was  initiated  by  an  appointment  scheduling  program 
each  morning  at  0500  (Pacific  time).  Interfacility  data  collection  began  one 
hour  before  SRAP  data  collection  beause  of  the  possibility  of  up  to  one  hour 
difference  between  the  receipt  of  interfacility  data  for  an  aircraft  and  its 
arrival  time.  The  batch  program  initiated  the  following  steps. 

D.2.1  DELETION  OF  OLD  INTERFACILITY  DATA  FILES. 

DOS  code  was  used  to  check  for  the  presence  of  Interfacility  data  files 
(Imddhhmm.AOL,  see  Appendix  A. 1.1)  on  the  C;\A0L  subdirectory.  If  data  files 
were  present,  they  were  deleted  from  C:\A0L. 

D.2. 2  DATA  COLLECTION  PROGRAM. 

IDPTC.EXE  was  the  executable  program  IDentif ication  Processor/TC  that  collected 
and  stored  the  interfacility  data  to  the  C:\A0L  subdirectory.  IDPTC.EXE  always 
started  interactively.  IDP.INP  was  a  re-directed  input  ASCII  file  containing  the 
responses  needed  to  initialize  IDPTC.EXE.  The  responses  are  explained  below; 

2  Processing  mode  -  ARRIVALS 

N  Include  all  aircraft  Id's 
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Y 


SFO  DATA 
Y 
B 
S 

22,00 

SFO 

<rrn> 

C : \AOL\SFODATA 


Copy  all  ARTS  Interfacility  (IF)  messages  pertinent  to 
ID-DAS  to  a  buffer  file 
Processing  title 
Specify  Start  and  Stop  time 

Begin  data  collection  immediately  upon  program  execution 
Specify  Stop  time 
Stop  time  -  2200  hours 

Output  filename  for  buffer  file  (SFO.AOL) 

Sets  default  output  filename  for  data  file  (default 
I mddhhmm . AOL) 

File  root  for  buffer  file 


D.2.3  FILE  BACKUP. 


The  daily  Interfacility  data  file  was  backed  up  on  the  C:\AOL\ARRIVALS 
subdirectory  and  on  the  A:  drive. 

D.3  WEATHER  DATA  COLLECTION. 


The  following  is  an  explanation  of  the  San  Francisco  International  Airport  (SFO) 
Weather  Data  Collection.  The  process  was  invoked  by  WXSF0.BAT  running  on  an  IBM 
compatible  computer.  WXSF0.BAT  was  initiated  by  an  appointment  scheduling 
program  each  day  at  0100  hours  Eastern  time  (2200  hours  Pacific  time).  The  batch 
file  executed  software  that  logged  onto  the  Kavouras  weather  network,  requested 
the  previous  30  SFO  weather  reports,  and  saved  these  reports  to  a  data  file 
(WXmmddyy.TXT,  see  Appendix  A. 1.3).  The  batch  program  consisted  of  the  following 
steps . 

D.3.1  DELETION  OF  OLD  WEATHER  DATA  FILES. 

DOS  code  was  used  to  check  for  the  presence  of  old  weather  data  files  in  the 
C:\WEATHER  subdirectory.  If  data  files  were  found,  they  were  deleted  from 
C : \WEATHER . 

D.3. 2  DATA  COLLECTION  PROGRAM. 


PCWX  started  the  communications  program  that  accessed  the  Kavouras  Weather  data 
base.  Since  PCWX  ran  interactively,  an  Extended  Batch  Language  (EBL)  batch  file 
was  needed  to  provide  the  necessary  response  to  log  on  to  the  system,  send  the 
command  "SA/RPTS-30  SFO,"  save  the  30  SFO  weather  reports  to  a  weather  data  file, 
and  log  off  the  system. 

D.3. 3  FILE  BACKUP. 

If  the  network  was  up.  the  weather  data  file  was  copied  to  the  K:\SF0\DATA 
subdirectory.  The  data  file  was  also  copied  to  the  C:\WEATHER\SFO_RPTS 
subdirectory  and  to  floppy  disk. 
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